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REMARKS/ARGUMENTS 

Claims 2-25 stand in the present application. Reconsideration and favorable 
action is respectfully requested in view of the following remarks. 

Initially, Applicants wish to note that the Examiner's designation of this Office 
Action as final is improper. In the first Office Action dated December 29, 2005, the 
Examiner rejected all claims over prior art which turned out not to be prior art at all. 
More particularly, the Examiner rejected all of claims 2-25 under 35 U.S.C. § 102(e) as 
being anticipated by Combs et al., U.S. Patent No. 6,766,348. However, Combs et al. 
was not properly cited as prior art against the present application and had to be 
withdrawn by the Examiner. Thus, Applicants' Amendment did not necessitate the new 
grounds of rejection presented in the current Office Action. Accordingly, the Examiner's 
designation of this Office Action as final is improper and Applicants respectfully request 
that it be withdrawn. 

In the Office Action, the Examiner has now rejected claims 2-25 under 35 U.S.C. 
§ 102(e) as being anticipated by Downs et al., U.S. Patent No. 6,1 12,243 (hereinafter 
referred to as "Downs"). Applicants respectfully traverse the Examiner's § 102(e) 
rejection of the claims. 

Downs describes providing remote, distributed processing of a task by employing 
a wide area network. Column 3, line 25 of Downs states that a "resource provider" is 
simply a computer system and Downs at column 3, lines 23 to 25 describes how a 
"resource allocator" is a server that assigns a particular task to one of a plurality of 
resource providers. A "resource requestor" is a client that needs computing or 
processing resources for a task (see Downs at column 3, lines 19 to 21). In this 
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context, the term "resource provider" indicates a source of resources, and does not 
indicate that the source will provide those resources at all times. Thus, the term 
"communications platform " in present claim 22 refers to the entity providing a 
remote distributed processing task in Downs, and each "subsystem " of the invention 
is equivalent to a "resource provider" of Downs. 

Unlike Downs, Applicant's invention provides that each subsystem (i.e., each 
"resource provider") has its own resource locator which in present claim 22 includes 
means to communicate to each of the resource locators (of the other subsystems of the 
communications platform). Accordingly, in present independent claims 13, 14 and 22 
this communication is achieved by broadcasting signaling messages to other resource 
locators. Independent present claims 10 and 23 require learning interface data and 
capability data from the resource broker (i.e., the resource allocator of Downs), so that 
signaling messages can be directly exchanged between call processing sub-systems. 
These features of the independent claims 10, 13, 14, 22 and 23 are not taught or 
suggested in Downs, as will be explained below. 

A central resource allocator is described in Downs as maintaining a list of 
potential sources of resources (i.e., a list of resource providers). However, the list does 
not indicate the actual availability of the resources. To obtain resource availability 
information, each computer system of Downs includes a local program manager 70 
which determines whether or not the resource provider 16 (the computer system of 
Downs) is able to handle the task in view of the current load on that computer system. 
To read Downs onto the present claims, the local program manager 70 must be 
equivalent to the resource locator of Applicant's invention. However, the local program 
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manager only provides an indication of resource availability back to the resource 
allocator in Downs. 

If a resource is available, the task(s) is (are) processed, if not, then the resource 
provider notifies the resource allocator in Downs that it cannot currently process the 
task. However, nowhere in Downs does the program manager 70 cause signaling 
messages to be sent (e.g., via a broadcast) to other "local" program managers hosted 
by other "computer systems" (see Downs, Col. 3, lines 55 to 64). Downs simply 
describes a "resource locator" which provides feedback to a "resource allocator" if 
resources are, or aren't, available at a particular time. If resources are available then 
the task is performed and the results (and not information on resource availability) are 
returned to the requestor (directly or via the resource broker). If resources are not 
available, then the resource allocator moves on to the next resource provider in the list 
and requests that resource provider to perform the task. 

In summary, in Downs a list of potential "resource providers" is maintained 
by a "resource allocator" - this "resource allocator" does not identify an 
"available resource" as being currently available - that information is derived by 
the local resource responding to a task request being received. Moreover, no 
"signaling" messages are ever broadcast or changed directly between local 
program managers in Downs. 

The communications between resource locators according to Applicant's 
invention comprises data identifying the source of the communication (the subsystem 
identity) and data indicating the resources available in the sub-system which has 
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generated the communication. In addition, the resource locator has means to broadcast 
the received requests for resources to each of said other subsystem resource locators 
by communicating signaling messages directly with each of said other subsystem 
resource locators (present independent claims 13, 14 and 22) or by signaling directly 
having learn the necessary interface information (present independent claims 10 and 
23). 

Applicant's invention is distinguished from Downs since the present claims 
indicate that each resource locator of a sub-system has to communicate messages with 
other sub-systems to enable knowledge of the current resources available at a sub- 
system to propagate throughout the communications platform. The indications provided 
reflect the available resources of the sub-systems in real time, not as per the static 
"resource provide list" which Downs et al describes which simply indicates that 
someone is willing to share their resources and not that the resources are in fact 
available. 

Applicant's invention is distinguished from Downs in that real-time availability of 
specific resources are made known to other sub-systems so that the processing of 
tasks can be dynamically assigned to sub-systems having available resources. A 
person ordinarily skilled in the art would read Downs as teaching that the local program 
managers might want to dynamically update the list of resource providers held by the 
resource allocator to achieve the same effect - but nothing in Downs would motivate a 
person skilled in the art to even consider how to overcome the technical hurdles 
involved with enabling local program managers on different computer systems from 
automatically communicating with each other to share out their processing tasks. 
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That Downs simply teaches a plurality of "resource providers" being associated 
with a single "resource allocator" which maintains a list of the resource providers is 
clear. See, for example, the Abstract ( "A resource provider initiates the process to be 
added to the resource allocator's list of providers . . . [i]f accepted the resource provider 
waits for a task from the resource allocator . . .") and column 6, lines 39 to 42 (it is clear 
that the resource provider only supplies with its application to the resource allocator "a 
description of the computing resources of that resource provider.") Moreover, Downs at 
column 6, lines 50 to 64 states: 

In processing step 216, the resource provider 16 upon 
receiving a task from the resource allocator 14. evaluates 
the current load on the computing resources of the resource 
provider by checking local resource table 72. 

In determination block 220, the local program 
manager 70 determines whether or not the resource provider 
is able to handle the task in view of the current load . ... If 
no, the resource provider notifies the resource allocator that 
the resource provider currently cannot process the task 
(processing step 228). 

(Emphasis supplied.) Thus, it should be clear that while Downs assesses the current 
availability of the resources of each computer system, this is performed locally and this 
information is not shared with other (potentially competing) computer systems nor is 
there anything in the description of Downs to indicate that signaling should be 
exchanged directly with the other resource providers to indicate current resource 
availability. Accordingly, it is respectfully submitted that the present claims patentably 
define over Downs. 

Therefore in view of the above remarks, it is respectfully requested that the 
application be reconsidered and that all of claims 2-25, standing in the application, be 
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allowed and that the case be passed to issue. If there are any other issues remaining 
which the Examiner believes could be resolved through either a supplemental response 
or an Examiner's amendment, the Examiner is respectfully requested to contact the 
undersigned at the local telephone exchange indicated below. 



CC:lmr 

901 North Glebe Road, 11th Floor 
Arlington, VA 22203-1808 
Telephone: (703) 816-4000 
Facsimile: (703) 816-4100 



Respectfully submitted, 



NIXON & VANDERHYE P.C. 
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